異なるBounded Context内でのConsistency
同期的に保つことを妥協することも考慮に入れる
非同期的であっても結果整合性を保っていれば良いと考える 2つのEntity間の連携の失敗をどう扱うかに着目して3パターンにわける ref Write-off
何もしない、破棄する
例えば、とあるECで顧客が注文した商品と異なるものを決済してしまった場合に、顧客にその商品を無料で提供する
スタバの例なら、誤って作ったコーヒーを廃棄する、という選択肢もありうる
店側はこれによってその商品分の損をするが、失敗がたまにしか生じないケースではこれは有用である
破棄せずに修正した方がコストが大きくなることもあるので。
これはConsistencyを保つこと自体を妥協する選択肢mrsekut.icon
Retry
再試行する
既に実行された操作をもとに戻すか、失敗した操作をやり直す
ECでの例なら、顧客にエラーした旨を示した後に、もう一度注文してもらう
Compensating Action
補償処理をする
システムを一貫性のある状態に戻すために、すでに完了した操作を元に戻す
undoする処理を発行するか、エラーの修正をする
ECでの例なら、誤って顧客に別の商品を送ってしまった場合に、顧客にお願いして商品を返品してもらう
その後、正しい商品を送るか、返金するなどする
赤伝もここに該当するのかなmrsekut.icon 1番目はConsistency自体を妥協する選択肢
2,3番目はConsitencyは保つが、即時に保つわけではない
少しの時間的な誤差があれど、結果整合性を保つようにする 数秒かもしれないし、数時間かもしれない
スタバの例にも書かれているが、即時に保つようにすると1つのtransactionに時間がかかりすぎてしまう 「レジで注文して、コーヒーを受け取る」が終了するまで次の客を捌けない
非同期でやれば、レジ係は注文を随時受けていれば良いし、コーヒー作り係はその中で効率的な順序でコーヒーを作れば良くなる
Aは、Bへmessageを送信して、Aは残りの続きの処理をやる
Bは非同期で自分の仕事をする
1番目の延長に2番目があるように見えるから分類として変じゃない？という気もするmrsekut.icon
まあ、延長であったとしても別に分類としておかしくはないかmrsekut.icon
「そういう選択肢があるよ」という文脈では正しい気がしてきたmrsekut.icon
参考
日本のスタバでのレジの非同期性を例にした説明
『Domain Modeling Made Functional』.icon の中でも参照されている